Fixed the handle issue by introducing our own handle type that can be legally converted into an unsafe.Pointer.

Note: i've now forked the repository and added more things on the main branch, that you might not want to have upstream. This includes improved garbage collection of wgpu resources, makeing calls to Release unecessary, as well as removing goal and moving the prebuild libraries into branches, as wgpu v27 is above the go get limit of 512mb.

It would be really nice to hear from the maintainers, if there are plans to either merge these improvements or cherry pick certain things out of it.

@kkoreilly and I will have a chance to discuss this soon and will post an update within a couple of weeks hopefully!

@oliverbestmann The changes on your main branch look good overall, and if you are interested in filing separate PRs for them, that would be awesome (no worries if not).

For the binary size limit, I wonder whether it might be easier to use different modules within the same branch rather than in separate branches? You could have separate go.mod files in each lib/android etc directory, right?

Could you briefly explain how you implemented the garbage collection and whether there are any major negative side effects of that?

Thanks for all of your contributions, and apologies again for our unresponsiveness, I've been very busy but should hopefully have more time to respond going forward.

Regarding the binary size limit: I am not sure if I tried that. I think the size limit is per shallow clone of the repository, not the module subdirectory.

Garbage collection: it is really just registering finalizers like here: https://github.com/oliverbestmann/webgpu/blob/main/wgpu/wgpu.go#L122 Special care needs to be taken when addRef is used, see a few lines above. The release method was made idempotent, so it can be called multiple times without crashing: https://github.com/oliverbestmann/webgpu/blob/main/wgpu/gen_types.go#L266
I did not experience any negative sideeffects.

I am currently also very busy due to $work and family, so I probably won't create multiple pull requests. I am sorry!

One consideration for timing of update of underlying libraries, assuming there remains some kind of cost to updating the libraries more frequently (hopefully @kkoreilly 's proposed solution might avoid that??) is the possible resolution of this issue: gfx-rs/wgpu#8119 -- this would probably be the single biggest issue fix for my usage.

@rcoreilly What is the timeline on gfx-rs/wgpu#8119? If it will be resolved soon, we can wait until then to finish this up. Otherwise we can work on merging this sooner (and I will experiment with the different approach for the binary libraries).

@kkoreilly IDK about the timing -- no evidence of progress or stated focus on this, so presumably not too soon. I think it would make sense for you to experiment with the approach for the binaries at this point.

https://github.com/oliverbestmann/webgpu is now updated to 25.0.4.0

https://github.com/oliverbestmann/webgpu is now updated to 25.0.4.0

Lets rephrase that, I've updated to wgpu-native v29.

@oliverbestmann I just tried to see if I could make a PR from your current main branch, and github says it is not possible because they have "entirely different commit histories".

In any case, it seems like you are continuing to actively update things, and I think at this point it would probably make sense for this repo to just point to yours as the definitive version, rather than trying to keep two copies in sync. @kkoreilly does this sound reasonable to you?

I will experiment with using yours now in cogentcore, and will probably file a PR for using glfw 3.4 -- would you be OK updating to that?

Yea of course. I can probably do the glfw update myself later today or tomorrow too. Otherwise feel free to report whatever issue you might have, I am happy to fix those asap.

I've updated to 3.4. There is a small issue if you want to use both x11 and wayland without build tags.
See go-gl/glfw#420

@oliverbestmann you don't have issues or discussions enabled on your repo page!

I am getting a nearly-100% reliable crash on Mac (Macbook Pro 2023, M3) in running the examples, which first appears in v1.30.0 (a254e95) when you updated to v29.0.0.0 Very occasionally it will run, but mostly it crashes, with the stack shown below.

If I use 337844f, examples run reliably.

This looks like a clear upstream, mac-specific issue. Not specific to glfw 3.4, but it may interact with glfw generically somehow -- seems like some kind of timing issue given the randomness of the crash. I'll look into the upstream system to see if I can reproduce anything there.

thread '<unnamed>' (21117468) panicked at src/lib.rs:4238:40:
invalid texture
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

thread '<unnamed>' (21117468) panicked at library/core/src/panicking.rs:225:5:
panic in a function that cannot unwind
stack backtrace:
   0:        0x1048423c0 - <std::sys::backtrace::BacktraceLock::print::DisplayBacktrace as core::fmt::Display>::fmt::hfd528c9d14c1136f
   1:        0x10486cf4c - core::fmt::write::h2ddadfca81aeb692
   2:        0x10480534c - std::io::Write::write_fmt::hc70e63382e9f29d2
   3:        0x104814f3c - std::sys::backtrace::BacktraceLock::print::hea663f6050de4073
   4:        0x10481b268 - std::panicking::default_hook::{{closure}}::hbcaf474e707f3b7d
   5:        0x10481b11c - std::panicking::default_hook::hff9145c2c6e89cdf
   6:        0x10481ba60 - std::panicking::panic_with_hook::he6431e171a67d1a5
   7:        0x10481b720 - std::panicking::panic_handler::{{closure}}::h42f8d27eb97efb5c
   8:        0x104815048 - std::sys::backtrace::__rust_end_short_backtrace::h0de35f7407a5e0d8
   9:        0x1047fbacc - __rustc[eb8946e36839644a]::rust_begin_unwind
  10:        0x1048b0b1c - core::panicking::panic_nounwind_fmt::h3db3f511675e5bd7
  11:        0x1048b0a1c - core::panicking::panic_nounwind::h50f882120c826cee
  12:        0x1048b0c20 - core::panicking::panic_cannot_unwind::h396781a6699a759f
  13:        0x10440a1d4 - _wgpuTextureCreateView
  14:        0x1043be610 - __cgo_0868a2725542_Cfunc_gowebgpu_texture_create_view
thread caused non-unwinding panic. aborting.
SIGABRT: abort
PC=0x18a1885e8 m=0 sigcode=0
signal arrived during cgo execution

goroutine 1 gp=0x140000021c0 m=0 mp=0x104c31aa0 [syscall, locked to thread]:
runtime.cgocall(0x1043be5cc, 0x1400007bc48)
	/opt/homebrew/Cellar/go/1.25.6/libexec/src/runtime/cgocall.go:167 +0x44 fp=0x1400007bc00 sp=0x1400007bbc0 pc=0x104347074
github.com/oliverbestmann/webgpu/wgpu._Cfunc_gowebgpu_texture_create_view(0x0, 0x0, 0x85b4adb40, 0x140000b8005)
	_cgo_gotypes.go:1768 +0x30 fp=0x1400007bc40 sp=0x1400007bc00 pc=0x10439b4a0
github.com/oliverbestmann/webgpu/wgpu.(*Texture).TryCreateView.func2(...)
	/Users/oreilly/go/src/github.com/oliverbestmann/webgpu/wgpu/texture.go:64
github.com/oliverbestmann/webgpu/wgpu.(*Texture).TryCreateView(0x14000112010, 0x100000104349280?)
	/Users/oreilly/go/src/github.com/oliverbestmann/webgpu/wgpu/texture.go:64 +0x1e8 fp=0x1400007bd20 sp=0x1400007bc40 pc=0x1043a31c8
main.(*State).Render(0x14000094080)
	/Users/oreilly/go/src/github.com/oliverbestmann/webgpu/examples/triangle/main.go:147 +0x4c fp=0x1400007be70 sp=0x1400007bd20 pc=0x1043aa21c
main.main()
	/Users/oreilly/go/src/github.com/oliverbestmann/webgpu/examples/triangle/glfw.go:49 +0x180 fp=0x1400007bf40 sp=0x1400007be70 pc=0x1043a9c90
runtime.main()

Enabled the issues tab on the repo.
I can reproduce the issue on MacOS. It looks like it is this issue: gfx-rs/wgpu#4779
If I continue if the returned nextTexture is not valid, the app works but loops very quickly.

	fmt.Println("Next Texture is valid:", nextTexture.IsValid())
	if !nextTexture.IsValid() {
		return nil
	}

I'll see what I can do, maybe I can add a workaround.

Done. I now correctly expose the status of the returned SurfaceTexture. You now need to handle this status and, for example, skip rendering if the surface is occluded. See the cube example for reference.

Thanks for the fix -- I was trying something similar in a fork but hoping to somehow avoid having every single program anyone ever writes to include that logic.. I don't see how to encapsulate it anywhere sensible though.

Here's the actual issue with links to all associated issues and PRs: gfx-rs/wgpu#9430